The present invention relates generally to code debugging in computer systems and, more particularly, to a method for enhancing debugger performance of hardware assisted breakpoints.
During development of application programs, developers use a debug program (debugger) to control the flow of application program execution and to inspect aspects of programs. The debugger allows developers to set breakpoints at specific locations in an application module so that the programmer can step into the code line-by-line, or resume execution of the program as required. Breakpoints corresponding to an address (termed “location breakpoints”) are resolved with assist from a hardware event facility. When an instruction is fetched from an address range being monitored by a hardware event facility, the facility will notify the debugger and the debugger will stop an application and display the location. Debugger location breakpoints that represent respective addresses are used to create the hardware event facility address range. Debuggers may also use breakpoints that are not hardware assisted.
In order to monitor multiple addresses, the hardware event facility maintains a single address range. That is, if a first location breakpoint is set for address 1000 in the system memory and a second location breakpoint is set for address 2000, then a range is set with a begin address of 1000 and an end address of 2000. Thus, all addresses between (and including) 1000 and 2000 are monitored. Where the begin and end addresses defining a range are far apart from one another, then the hardware event facility is forced to monitor a large address range, which takes more time than monitoring a small address range. As a result, a debugger with active location breakpoints representing a large address range becomes noticeably less efficient. Value would be therefore be added to a debugger if the maximum address range monitored by a hardware event facility could be kept to a minimum.
Whenever a debugger user requests to set a breakpoint, it must be validated before it can be accepted by the debugger. The validation process typically ensures that the information provided by the user represents a real program address. If the location breakpoint can be validated then it is set as active, thus affecting the hardware event facility address range. On the other hand, if the breakpoint cannot be validated, the debugger will not allow it to be set.
In addition, debuggers may also provide an option in which a deferred breakpoint may be created; that is, a “deferred” breakpoint is one that is validated at a later time. As such, deferred location breakpoints do not affect the hardware event facility address range prior to validation thereof. Conventionally, deferred breakpoints are validated as additional application modules are entered. If a deferred location breakpoint can be validated at such a time, then its state is changed from “deferred” to “active” and it will result in redefining the hardware event facility address range if it falls outside the existing range. If it cannot be validated, the breakpoint remains in a deferred state.
Unfortunately, as an application debugged in a conventional manner enters into additional modules, the potential exists for the address range to grow very large as more location breakpoints become active. This has the effect of making the hardware event facility less efficient and will slow the performance of the debugger. Accordingly, it would be desirable to be able to enhance debugger performance of hardware assisted location breakpoints across multiple modules.